Within a network such as an Internet Protocol (IP) network a stream of packets from a source application to a destination application is called a flow. How the packets forming a flow should be dealt with by the transport network depends very much on the needs of the application, which in turn defines the needs of each flow. Four parameters can usually be defined to specify the performance metrics required of the transport network by a flow, being the bandwidth required (the data rate), delay (being how long the network takes to transport a packet from source to destination), jitter (being the variation, such as standard deviation, in packet arrival times with respect to packet transmission times), and reliability (in terms of the extent to which the flow can tolerate packet loss). Together these parameters define the quality of service (QoS) the flow requires. A particular quality of service which any particular flow requires in terms of the characteristics of the four parameters noted above will depend on the application from which the flow is being sent or received. For example, an email application may require high reliability, but have low expectations for bandwidth, delay, or jitter, whereas a video conferencing application will have much higher expectations in respect of delay, jitter, and bandwidth, but can tolerate a degree of packet loss.
Much work has been undertaken in the past by members of the Internet Engineering Task Force (IETF) to formulate mechanisms for the provision of quality of service in transport networks, and in particular IP networks. One branch of this work led to a number of flow based QoS mechanisms, known as “Integrated Services”. These are described in a number of IETF RFCs, and in particular RFCs 2205 to 2210. Two specific types of flow based QoS were considered under the auspices of integrated services, being the “Guaranteed Delivery” service described in IETF proposed standard RFC 2212, and the “Controlled Load Delivery” service described in IETF RFC 2211. The characteristics of the Guaranteed Delivery service and the controlled load delivery service are shown in the table given in FIG. 12. In particular, Guaranteed Delivery provides a fixed bandwidth, together with a fixed upper bound for delay. Very low jitter is also provided, and the service is assured in that there should be no packet loss. The Guaranteed Delivery service therefore represents a high quality of service from the transport network.
For Controlled Load delivery, no rate guarantees are given but limits are placed on packet delay, jitter, and loss in that a low delay and jitter, and little loss are specified. The main IETF protocol for the provision of the Integrated Services architecture is the resource reservation protocol (RSVP) described in RFC 2205, RFC 2210, and others.
As described in RFC 2210, an application instance participating in an RSVP session as a data sender registers with RSVP. One piece of information provided by the application instance is the Sender TSpec describing the traffic the application expects to generate. This information is used to construct an RSVP SENDER_TSPEC object, which is included in RSVP PATH messages generated for the application.
The sending application also constructs an initial RSVP ADSPEC object. This adspec carries information about the QoS control capabilities and requirements of the sending application itself, and forms the starting point for the accumulation of path properties described below. The ADSPEC is added to the RSVP PATH message created at the sender.
Typically the default ADSPEC supplied by the host RSVP in this case would support all QoS control services known to the host, however the exact behavior of this mechanism is implementation dependent.
The ADSPEC is modified by subsequent network elements as the RSVP PATH message moves from sender to receiver(s). At each network element, the ADSPEC is passed from RSVP to the traffic control module. The traffic control module updates the ADSPEC, which may contain data for several QoS control services, by identifying the services mentioned in the ADSPEC and calling each such service to update its portion of the ADSPEC. If the traffic control module discovers a QoS control service mentioned in the ADSPEC but not implemented by the network element, a flag is set to report this to the receiver. The updated ADSPEC is then returned to RSVP for delivery to the next hop along the path.
Upon arrival of the PATH message at an application receiver, the data in the SENDER_TSPEC and ADSPEC objects is passed across the RSVP API to the application. The application (perhaps with the help of a library of common resource-reservation functions) interprets the arriving data, and uses it to guide the selection of resource reservation parameters.
An application receiver wishing to make a resource reservation supplies its local RSVP with the necessary reservation parameters. Among these are the QoS control service desired (Guaranteed or Controlled-Load), the traffic specifier (TSpec) describing the level of traffic for which resources should be reserved, and, if needed by the selected QoS control service, an RSpec describing the level of service desired. These parameters are composed into an RSVP FLOWSPEC object and transmitted upstream by RSVP.
At each RSVP-aware point in the network, the SENDERTSPECs arriving in PATH messages and the FLOWSPECs arriving in RESV messages are used to request an appropriate resource reservation from the desired, QoS control service. State merging, message forwarding, and error handling proceed according to the rules of the RSVP protocol.
Finally, the merged FLOWSPEC object arriving at each of an RSVP session's data senders is delivered to the application to inform each sender of the merged reservation request and properties of the data path.
In addition to flow based algorithms such as Integrated Services, IETF also devised a class based quality of service architecture, known as “differentiated services” (DiffServ). With class based service entire classes of flows (e.g. Internet telephony flows) are provided with the same quality of service, thus meaning that the quality of service mechanism does not need to handle individual flows. In this respect, the DiffServ architecture is thought to be more straightforward than the Integrated Services architecture.
The choice of service classes in a DiffServ environment is up to each network operator, but IETF has defined network independent service classes. One particular service class is “Expedited Forwarding” described in RFC 3246. Expedited Forwarding, referred to as “EF”, provides a fixed rate, with either low or no delay, jitter, or packet loss.
An alternative service class under the DiffServ architecture is “Assured Forwarding” described in RFC 2597 and referred to as “AF”. Within Assured Forwarding four priority classes are prescribed, each class having its own resources. The four classes of packets are then subject to traffic shaping such as using leaky or token bucket algorithms to maintain the quality of service. The rate given by assured forwarding depends on other flows within the same class, and no guarantees are given for delay or jitter. However, packet loss is unlikely as long as traffic is within its specified envelope.
Whilst the Integrated Services and Differentiated Services architectures appear sound in theory, in practice they have proved difficult to apply, principally because they require the sending application to know the particular quality of service architecture used by the transport network. However, as apparent from the above, at least two different quality of service architectures have previously been proposed, within which other different mechanisms can be employed to provide QoS. Due to the proliferation of different technologies, therefore, QoS requester mechanisms have not been built into applications typically, due to the necessity to build in compatibility with all the different QoS architectures. However, any particular application has a general idea as to its QoS requirements in terms of whether it can accept an elastic service, a real time service but with packet loss, or a real time service but with no packet loss. Additionally, an application also tends to have an idea of its bandwidth and packet size characteristics. It would therefore be better to permit applications to specify QoS in a different form, which can then be translated into transport network technology specific QoS for the resource reservation.
Moreover, with the different types of QoS there is at present no integrated technique to allow for the coordination of admission control decisions over a large scale multi-domain network, where the individual domains may be employing different QoS architectures. RSVP as described above provides for the coordination of QoS in an Integrated Services architecture where every node is RSVP enabled, but is inherently limited to operation with RSVP-enabled nodes. Thus, if every node a flow must traverse is an RSVP node, then RSVP effectively co-ordinates the various QoS admission control decisions at those nodes. However, where multiple domains are involved which use different QoS architectures, e.g. a DiffServ architecture, or do not make any QoS reservations or guarantees at all, then RSVP is not able to provide co-ordination.
The paper “A Bandwidth Reservation Protocol for Hard QoS Guaranteed Differentiated Services” by Wen-Tsuen Chen, Chin-Fu Lin and Chung-Shih Tang (ICC 2001, IEEE International Conference on Communications, Helsinki, Finland, 11-14 Jun. 2001, Conference Record, pages 1792-1796), aims to provide a hard QoS guaranteed service with end-to-end behaviour across domains in DiffServ, and appears to partially describe a method to coordinate EF networks. The method uses different messages depending on whether the service concerned is EF or AF, so the protocols depend on the type of QoS.
Referring to prior patent documents, EP1589696 relates to systems and methods for implementing resource allocation in network communication, and aim to solve the end-to-end QOS problem through dividing a communication network into a plurality of QOS domains and managing them. WO02056564 relates to methods and systems for providing end-to-end QoS within a mobile telecommunication system comprising at least one network means such as a Core Network connected to at least one Radio Access Network using IP based transmission.
There is thus a need for a further signalling protocol and associated techniques to allow for the co-ordination of QoS related admission control across multiple domains, each of which may have different QoS architectures.